This invention relates generally to programming of digital computers, and, more particularly, to a method for enabling compilers or interpreters to use identifiers found at run time in a map container object in a manner similar or identical to identifiers declared at compile time.
In the abstract, a namespace is a space within which names are defined, can be differentiated from each other, and have unique identity. Programming languages always define at least one namespace, allowing names to be defined which are differentiated from each other, and which are used to identify nameable entities in the namespace. Many programming languages, including C++ and Java®, support multiple namespaces, either explicitly or implicitly, or both. (Java® is a registered trademark of Sun Microsystems, Inc.) For instance, C++ treats every class as its own namespace, and additionally includes a namespace definition declaration, allowing the definition of previously non-existent namespaces, in which new unique names may be defined.
Various systems and subsystems implemented in computers, other than programming languages, support namespaces, which identify by (typically human-readable) character strings objects of classes supported by those subsystems. For example, a hierarchical filesystem provided by an operating system supplies a namespace where each name identifies either a file (a sequence of bytes on a storage medium) or a directory containing files and other directories. As another example, the IEEE POSIX® operating system specification, as defined by “IEEE/ANSI Std 1003.1, 1996 Edition: Information Technology—Portable Operating System Interface (POSIX&)—Part 1: System Application: Program Interface (API) [C Language]”, which is incorporated herein by reference, defines an “environment” that supplies a namespace where each name identifies an arbitrary string of characters of any length. (POSIX® is a registered trademark of The Institute of Electrical and Electronic Engineers, Inc.) As a further example, Uniform Resource Identifiers (URIs) defined by “IEC RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax”, which is incorporated herein by reference, define a namespace encompassing the entire Internet, such that any object reachable via the Internet may be named. As a further example, CORBA®, as defined by Object Management Group, “The Common Object Request Broker: Architecture and Specification, Minor revision 2.3.1”, Needham, Mass., Object Management Group, October 1999, which is incorporated herein by reference, defines an Interface Repository, containing named definitions of interfaces and other related objects, which are named by human-readable identifiers. (CORBA® is a registered trademark of Object Management Group, Inc.) These namespaces hereinafter will be referred to as “non-programming namespaces”.
It is desirable that computer programs can access objects in these non-programming namespaces, in order to find objects by name, to read and write the objects, to create and delete named objects, and to invoke methods defined on the objects. To this end, it is customary that for a given computer programming language (such as C++ or Pascal), and a given kind of non-programming namespace (such as a filesystem), an application programming interface (API) to that namespace is defined. Such an API typically defines a function for each of the aforementioned operations. The functions that locate named objects in a non-programming namespace often accept as arguments strings of characters which are the names of objects sought. These strings are not considered names in the source programming language used to program the function calls. Therefore, objects defined in non-programming namespaces are named, created, deleted, and manipulated using function calls the meaning of which is defined entirely outside the source programming language. By contrast, objects defined using the source programming language are named, created, deleted, and manipulated using statements defined by the language itself, and those statements are interpreted by a compiler or interpreter of the language. As a result, much of the expressiveness of a programming language cannot be employed by program source code which manipulates objects in a non-programming namespace. Additionally, no uniformity exists in referencing by name objects defined using a programming language versus objects defined outside a programming language.
In practice to date, among APIs to a number of non-programming namespaces defined for a single programming language, there is little or no commonality between the functions of distinct APIs intended to perform similar or identical operations on the objects of their respective non-programming namespaces.
Accordingly, there is a need for a mechanism that provides access to objects and their names defined in non-programming namespaces, which is integrated with access to objects and their names defined in programming namespaces, and which is uniform across disparate kinds of namespaces.